home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Collections: Taifun
/
Taifun 220 (1992-09-10)(Manewaldt, A.)(DE)(PD).zip
/
Taifun 220 (1992-09-10)(Manewaldt, A.)(DE)(PD).adf
/
Schutz
/
VT2.44d
< prev
next >
Wrap
Text File
|
1992-09-12
|
58KB
|
1,299 lines
ab VT2.42 ist die Parameterabfrage fuer die Verwendung
in der startup-sequence entfernt !!!!!
Begruendung: das Prg ist inzwischen viel zu gross fuer die
Verwendung in der startup-sequence
HINWEIS:
- Bitte lesen Sie zuerst VT.LiesMich. Danke !
- Serienersteller sollten vorher Kontakt mit mir aufnehmen !!!
Heiner
WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG
Entgegen anderslautenden Geruechten ist VT KEIN Hinter-
grundprogramm (???). Der Speicherverbrauch ist viel zu
hoch. Sie starten bitte VT, testen ihren Speicher und die
Disks. Bitte sind Sie so vernuenftig und sehen Sie ein, dass
nicht gleichzeitig ein anderes von Ihnen gestartetes Programm,
Schreibzugriffe auf die gerade zu testende Disk ausfuehren darf.
Es sollte bekannt sein, dass jeder Schreibzugriff die Disk-
struktur veraendert ( unter Umstaenden wird auch der BitMapBlock
verlagert !!).
Danke
WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG WICHTIG
WICHTIG 2:
Mit KS2.04 koennen Hardlinks (mit makelink) und Softlinks
(z.B. mit Assembler) erzeugt werden. VT kommt mit Hardlinks
unter KS1.3 und KS2.04 zurecht. Softlinks verkraftet VT nur
unter KS2.04 . Mit KS1.3 stuerzt VT beim File- u. BlockITest
mit GURU B ab. Die Links werden im FileRequester aber auch
mit KS1.3 erkannt und ohne GURU ausgewiesen (andere Routine).
Hinweis: 26.01.92
Im Januar 92 sind mehrere Anrufe gekommen und zwei Disks geschickt
worden, bei denen der BlockKetteTest den Rueckzeiger auf den
Fileheader als falsch erkennt. Nach Commodore zeigt beim
OFS ein Langwort im DataBlock auf den Fileheaderblock zurueck.
Bei diesen Disks zeigt das Langwort auf den EIGENEN Datenblock.
Durch die doppelte Verkettung sind diese Files meist lauffaehig.
Ein Einzelfilecopy der ganzen Disk behebt diesen Fehler.
Versuche mit dem CopyBefehl der neuen WB und ROM KS2.04 ergaben,
dass das Betriebssystem mit OFS WEITERHIN diesen Rueckzeiger
setzt !!!! Es muss also ein UtilityPrg im Umlauf sein, das diesen
Fehler erzeugt. Moeglichkeiten:
- einfacher CopyBefehl (unwahrscheinlich)
- DiskOptimizer
- DirUtility mit eingebautem Copybefehl
- DiskCopyPrg mit Option Dir-orientiert
- oder eine Moeglichkeit, die ich vergessen habe
Wer kennt ein Prg ?????
Erste Antworten Feb. 92: alle nennen den gleichen DiskOptimizer-Namen
( kein PD !!!)
XCopy 5.2 Fehler (Orginal ??):
Anfang April habe ich einige Disketten bekommen, mit der Bitte, sie
zu ueberpruefen. Jeweils bei einem File hat VT bei dem Block-Ketten-
Test bad T.Data ausgegeben (d.h. die Kennung eines DatenBlocks = $8
stimmte nicht ). Es war IMMER der Block 2 (also gleich nach dem BB).
Telephonische Rueckfragen ergaben, dass der Xcopy-BB IMMER nach-
traeglich installiert wurde. Ich vermute nun, dass anstatt 1024
Bytes in einer Schleife 1028 Bytes zurueckgeschrieben werden. Bitte
fuehren Sie mit ihrem Orginal-Xcopy einen entsprechenden Test durch
(WICHTIG: Block 2 MUSS von einem File belegt sein). Falls Sie
danach $0 anstatt $8 im 2.Block 0.Langwort finden, informieren Sie
bitte den Hersteller und MICH .
HinweisA Juli 92:
(N) = nach meiner Meinung ein Nutzprg, das Vektoren verbiegt, die
auch von Viren verbogen werden.
(H) = nach meiner Meinung ein harmloser BB
(L) = nach meiner Meinung ein BB der mit KS2.04 und/oder 68030
nicht sauber laeuft
HinweisB Juli 92:
Falls Sie bei einer Disk Fehlermeldungen bekommen, probieren Sie
die Disk mit ihrem 2.LW. Oder machen Sie ein einfaches diskcopy
(bitte KEIN nibblecopy). Oder verwenden Sie turbobackup. Es kann
sein, dass die kopierte Disk KEINE Fehler mehr zeigt. Allerdings
sollten Sie dann bedenken, dass ein LW sich verstellt hat. Ent-
weder ihr LW oder das LW auf dem die "OrginalDisk" erzeugt wurde.
Hinweis Aug 92:
Im Icon ist ein Stack von 4096 eingetragen. Dies kann fuer eine
grosse Festplatte bei FileTest zu wenig sein. Tragen Sie dann
bitte 8192 oder mehr ein. Beim Start von VT aus Shell muss dann
zuerst der Stack-Befehl eingegeben werden. Danke
Sollte behoben sein: 17.08.92
letzte Aenderung: 10.09.92
Aenderungen seit VT2.43
WICHTIG !!!!!
Um Linkviren SICHER zu finden, die sich HINTER
den 1.Hunk linken, MUESSEN Sie FileTest auf-
rufen !!!
- Express2.20 09.09.92
2 Zerstoerungsfiles
- D-Structure A u. B 08.09.92
2 File-Viren
- Compuphagozyte 4 u. 4a 08.09.92
(FileVirus)
- teilweiseunterstrichene Buch- 07.09.92
staben fuer Tastatur (gilt
im Moment nur fuer Df0:)
- drucke erweitert Aug 92
- aus VT-kennt ausgegliedert: Aug 92
- VT-and.BB
- VT-Cruncher
- Vt-Druck
- VT-Filerequester
- VT-Nutz.Prg
- Stack-Bedarf wieder reduziert Aug 92
(hoffe ich) (auf 4096)
Programmvoraussetzungen:
- fuer den PrgAblauf werden bis zu 290Kb Mem (Fast und Chip (falls kein
Fastmem vorhanden, dann nur Chip)) benoetigt: z.B. fuer
- 180Kb eigenes Prg
- 20Kb Hauptfenster (Betriebssystem)
- 15-20Kb fuer Requester (Betriebssystem)
- 5Kb kurzfristig fuer neu eingelegte Disk (Betriebssystem)
- 20Kb FileRequester
- usw.
Hinweis: Falls Probleme mit nur 512Kb-Speicher (a500), bitte startup-
sequence abbrechen und OHNE loadwb aus cli starten.
Stack-Befehl nicht vergessen (bei Bedarf z.B. stack 8192)
Danke
- KickRom V1.2 oder V1.3
- laeuft mit Kick V1.3 auf A3000
- sollte mit 37.175 auf A3000 laufen
- sollte mit 39.101 auf A3000 laufen
- sollte mit KS2.04 auf A500Plus laufen
- sollte mit KS2.05 auf A600 laufen (37.300) 4.LW
- sollte mit Commodore-CDTV laufen (aber NUR Disk, NICHT CD-Test)
(Laufwerksinfo fuer CD: lowCyl = 0 ist ok. , aber
1 Block pro track
1 Surface (waere kein Problem)
1 Cyl pro CD ????
HighCyl = 0 was soll das !!!! Wer kennt Abhilfe. Ein
einfacher FileTest waere natuerlich moeglich mit DOS-Funktionen,
entspricht aber nicht meinen Vorstellungen. Deshalb wird
CD0: nicht angezeigt)
- laeuft n i c h t mit ZKick, LKick oder ReKick auf A2000
- laeuft n i c h t mit Kickit B1-Bx auf A2000
- mit gepatchten Kickepromversionen erwarte ich Probleme
- mit KickDisk V1.2 Vers.33.166 laeuft mein Prg. nicht
(Trackdisk.device liegt an anderer Stelle)
- PalScreen (geht nicht immer, ist Commodore bekannt !!)
bei KS1.2 u. 1.3 bei NTSC Angebot Kreset oder Interlace
Prg.ablauf:
- prg im Cli starten oder von WB starten
Einschub:
- Test auf KickRomV1.2, V1.3 oder V2.0
- Test auf PAL-Screen
- ein Fenster wird geoeffnet (muss immer kurz erscheinen !!!)
- einige Vektoren werden getestet und angezeigt
- wenn Veraenderung, dann:
- Suche nach bekannten Viren (s.u.) beginnt
- falls erfolgreich
- Namensausgabe
- Vektoren werden zurueckgesetzt und angezeigt
- Virenprogramm wird mit Nullen ueberschrieben
- also kein Reset mehr notwendig
- falls erfolgreich 2
aus programmtechnischen Gruenden, ist es bei einigen Viren not-
wendig, vor der Vektoranzeige das VirusPrg. zu loeschen (z.B.
Extreme) und mit Null aufzufuellen. Es taucht dann der Requester
auf:
XYZ-NameVirus
war im Speicher
Weiter Weiter
- falls Nein
- Request unbekanntes Programm
im Speicher
KReset weiter
- weiter:
es werden keine Veraenderungen vorgenommen und das
Programm beendet.
- KReset:
- Vektoren werden zurueckgesetzt
- reset wird ausgefuehrt
dieser Weg wurde gewaehlt, damit zukuenftige Viren mit
eigenen Task (hier reicht das Zuruecksetzen der Vektoren
nicht mehr, sondern es muss auch der/das Task entfernt werden)
geloescht werden koennen, ohne den Computer auszuschalten.
ARBEITS-Fenster:
================
ZWEI BITTEN falls Sie Schreibzugriffe planen !!!!!!
- Setzen Sie im VorPrg. die OrgVectoren, auch wenn Sie ein fuer
Sie wichtiges Resident-Prg. spaeter neu laden muessen
- Arbeiten Sie mit einer Disk-Kopie (bedenken Sie, auch mir
koennen Fehler unterlaufen !!!!)
Erklaerung:
Im Hauptfenster sind in manchen Gadgets Buchstaben unterstrichen.
Wenn Sie die entsprechende Taste druecken, wird bei Gadgets, die
in DF0: und DEVS unterteilt sind, die Aktion fuer DF0 ausgeloest.
Bei Gadgets ohne Unterteilung sollte eine Auswahl erscheinen
(z.B. Listen).
Ende = Prg.Ende
----
Listen:
-------
Mit diesem Programmteil koennen Sie sich einen schnellen
Ueberblick verschaffen, was in ihrem Computer im Moment
aktiv ist (z.B. SnoopDos) oder einen Virus-Task finden.
Falls bei Resident eine Adresse NICHT ins ROM (>$F8 o. >$FC)
zeigt, fangen Sie bitte mit Nachforschungen an !!!
Hinweis: Die Listen werden pro Aufruf nur 1x gelesen.
Der Task-Zustand aendert sich also NICHT !!
Hinweise zu IntVec:
Unter KS2.04 werden Aud0-3 erst nach dem 1.Aufruf des
audio.device eingebunden.
Es wird jeweils auch die Ausgangszeile eines IntVec an-
gezeigt, obwohl die Verwaltung über Listen erfolgt. Aber
VirenProgrammierer halten sich nicht an Listen und ver-
biegen direkt (sehr beliebt Nr.5). Deshalb diese Zeilen.
(Beispiel DASA)
Abbruch mit ESC-Taste oder re.Maustaste
Ausdruck mit druck
z.Zyl:
------
- physikalisch Zylinder 0
- physikalisch Zylinder 1 s.u.
- logisch Zylinder 0
- Root-Zylinder
- logisch Zylinder variabel s.u.
- Root-Zylinder PC0: u. PC1: s.u.
- Abbruch mit ESC-Taste oder re.Maustaste
- Ausdruck des gerade sichtbaren Blocks mit Druck-Gadget
Hinweis: Der Rootblock einer Festplatte muss NICHT in
Block 0 des Zylinders liegen, sondern nur in Block 0
eines Tracks von diesem Zylinder (rechnen Sie nach).
Beispiel: Ihre Festplatte hat 6 Oberflaechen und 33
Bloecke pro Zylinder. Dann kann der RootBlock auch in
Block 99 des Zylinders liegen. Sie muessen dann also
mit dem PropGadget durchklicken um ihn zu finden.
( Hoffentlich habe ich keinen Rechenfehler gemacht )
Eigentlich war dieser Programmteil nur fuer Festplatten ge-
dacht. Da aber das Ausblenden der restlichen Laufwerke mehr
Aufwand gebracht haette, koennen Sie jetzt von jedem LW den
physikalischen Zylinder 0 anschauen (also auch den kompletten
French-Kiss-BB-Virus. Die 6 Bloecke fehlen mir IMMER noch!!).
Blockwechsel mit PropGadget (rechts). Programmteilende mit
ESC-Taste. Blockanzeige rechts oben (es beginnt mit 0 !!).
Den angezeigten Block (512Bytes) koennen Sie nach dem Ver-
lassen des PrgTeils im FileRequester abspeichern.
Warum dieser Programmteil:
Weil Commodore festgelegt hat, dass der Rigid-Bereich ausser-
halb von jeder Partition liegen soll. Nun koennen aber fast
alle DiskMonitore (Stand: Jan 92) nur logische Bloecke an-
zeigen. Glauben Sie nicht, dann bitte selbst ausprobieren.
Sie werden Block NULL ihrer ersten Partition sehen, aber nicht
Block 0 von Zylinder 0 .
Nun gibt es aber schon BB-Viren, die sich unbeabsichtigt
(nehme ich mal an) auf Block 0 von Zylinder 0 schreiben koennen,
da das trackdisk.device nicht gefordert wurde. Als Schutz
konnten Sie schon laengere Zeit mit VT Block 0-3 von Zylinder 0
abspeichern und bei Bedarf zurueckinstallieren. Hab ich selbst
bei einem verzweifelten User schon einmal gemacht und hat
die Festplatte vor der Neuformatierung bewahrt.
Durch Telephongespraeche hat sich herausgestellt, dass SCSI-
Festplatten zunehmend gekauft werden, dass man sich aergert,
weil man nicht sieht was im Rigid-Bereich steht (oder haben
Sie mit ihrem Kontroller einen solchen Monitor mitbekommen?)
oder Angst hat, dass es jemand einfaellt hier ein VirusPrg
gezielt unterzubringen.
Deshalb dieser Programmteil
Fehlermeldungen: siehe bei BlockITest
Disk bad Pech gehabt, ein Track dieses Zylinders auf der
HD wurde beim Low-Level-Format als unbrauchbar
erkannt und ein ErsatzTrack benutzt (hoffentlich).
VT sucht den ErsatzTrack NICHT. Ziehen Sie bei
Bedarf das PropGadget weiter. Vielleicht ist der
naechste Track des Zylinders in Ordnung.
Bei Disk: Track defekt oder Fremdformat !!!
Hinweis2: wenn Sie die Arbeit abbrechen (re Maustaste), dann
koennen Sie mit dem Filerequester den letzten gezeigten Block
abspeichern.
zu physikalisch Zylinder 1 :
Die Software von einigen Kontrollern sperrt 2 Zylinder fuer
den Rigid-Bereich. Jetzt koennen Sie auch diesen Bereich an-
schauen und je 1 Block abspeichern (s.o.) .
zu logisch Zylinder variabel :
Schauen Sie bitte zuerst in Tools, LWInfo die Werte von LowCyl
und HighCyl nach. Danke
Rechnung fuer max. moeglichen logischen Zylinder:
max. log. Zyl. = HighCyl - LowCyl
Falls Sie einen hoeheren Wert waehlen, sollten Sie im Prgverlauf
eine Fehlermeldung erhalten (hoffe ich).
Also z.B. bei einer Disk: MaxLogZyl = 79 - 0 = 79
oder:
LOWCyl = 304 HighCyl = 804
max. log. Zyl = 804 - 304 = 500
dann ergibt sich
phys. LowCyl 304 = log. Zyl 0
phys. HighCyl 804 = log. Zyl 500
also umfasst die Partition eigentlich 501 Zylinder !!!!
Der hoechste einstellbare Wert fuer Festplatten: #9999
- Root-Zylinder PC0: u. PC1: (df0: u. df1: als MSDOS-Laufwerke)
Suchen Sie bitte das Directory in Zylinder 0 und meist Block 7.
(gilt nur fuer 720kb MSDOS-Disketten, nicht fuer 1,2mb o 1,4mb)
Vergl. : (Vergleiche)
--------
- Abbruch: ESC-Taste oder re.Maustaste
- Ausdruck von 2048 Bytes mit Druck-Gadget
je 1024 Bytes
- lege Testbeginn fuer 2. Objekt fest oder 0
Es geht nur eine Verschiebung in 2-Byte-Schritten.
Diese Einstellung muss ZUERST gemacht werden, wenn der Beginn
beim 2. Objekt verschoben werden soll !!!!
Warum:
Manche BootblocksaveUtilities legen vor dem eigentlichen BB
1 LW zur Erkennung ab. Sie muessen also 4 einstellen.
Sie haben ein bekanntes Linkvirusfile. Sie wollen dieses File
mit einem anderen File vergleichen. Da das 2. File mehr Hunks
hat (Zahl steht im 3.LW) muessen Sie den den Testbeginn fuer
das 2. File solange verschieben, bis $000003E9 deckungsgleich
sind.
- BB <-> BB
lade 2 BB jeweils von Track 0 .
So koennen Sie auf Nachahmungen testen. Oder Sie wollen den
codierten Bereich herausfinden, von einem BB-Virus, der sich
bei jedem Schreibvorgang neu codiert (z.B. mit Inhalt von $DFF006).
- BB <-> File
vergleiche BB von Track 0 mit einem archivierten File
- File <-> File
vergleiche zwei Files
VT - Prefs :
------------
- mit Seitenstopp Ja / Nein
- BB mit expansion.lib Ja / Nein
- DOS2/3 ab KS2.04 Ja / Nein
- DOS4/5 ab KS3.0 Ja / Nein
- AddBuffers 200 ab KS2.04 0 / 200
- Warnton Ja / Nein
- Drucker bereit ? Ja / Nein
- Druckrequester ? Ja / Nein
zu Druckrequester ? :
NUR fuer FileTest und Tools/SystemTest notwendig.
Fuer diese zwei Programmpunkte MUSS Ja eingetragen sein, damit
ein Ausdruck moeglich wird. Bei den zwei Programmpunkten koennen
Sie dann im Druckrequeseter immer noch verneinen. Es hat mich
aber beim FileTest von 20 Disks der DruckRequester am Anfang
genervt, weil ich meist nicht drucken wollte. Deshalb kann er
in VT-Prefs mit Nein unterdrueckt werden.
zu Drucker bereit ? :
Wenn alles in Ordnung ist, bekommen Sie "SOFORT" ein Ja .
Falls es Probleme gibt, kommt erst nach rund 30 Sekunden eine
Meldung vom Betriebssystem zurueck. VT ist dafuer NICHT verant-
wortlich !!! Probieren Sie es aus mit WB/Tools/initprinter .
Auf ihrem Bootmedium (Disk o. HD) muessen sein:
prefs, parallel.device, printer.device, und z.B. NEC
Vor dem Anklicken von 'Drucker bereit ?' MUESSEN sie einmalig ihre
Bootdisk einlegen !!!!
Weitere Fehlerquellen:
- ist der Drucker an ?
- ist er Online ? (LED)
- ist Papier da ?
- ist er ueberhaupt angeschlossen ?
- haben sie ueberhaupt einen Drucker ?
(Das glauben Sie nicht? War der Grund fuer eine Reklamation
im MSDOS-Bereich)
zu Warnton :
aktiviert zu manchen Requestern als Zusatz einen Ton
zu DOS4/5:
Diese BB-Kennung ermoeglicht ein DirCache auf Disk. Ein neuer
BlockTyp ($20 oder $21) wurde eingefuehrt. Bitte verwenden Sie
diesen BB nur wenn Sie haben:
KS3.0, l:DCFileSystem, neue Befehle: format, install, info
Hinweis: DOS4 liefert mit dem alten Filesystem Phantasiewerte
in Bezug auf fileinfo (numblocks). Lassen Sie die Finger davon,
bis alle Bugs entfernt sind. VT versucht diese Klippe bei der
Erkennung von DOS4 im BlockKettenTest zu umgehen.
DOS5 liefert brauchbare Werte.
zu DOS2/3: (International)
Diese Kennungen wurden im ROM KS2.04 gefunden.
DOS2 = OFS
DOS3 = FFS
Diese BB`e koennen mit install von WB KS2.04 N I C H T er-
zeugt werden.
Diese BB`e sind von Commodore N I C H T dokumentiert.
Benutzung also auf E I G E N E Gefahr !!!!
VT schreibt hier immer den BB mit expansion.library .
Unter KS1.3 sind diese BB`e NUTZLOS , da eine solche Disk
als not a Dos-Disk eingestuft wird !!! (die Kennungen befinden
sich nicht im ROM)
Nachtrag: 04.03.92
DOS2/3 = International
Koennen mit WB2.1 erzeugt werden.
format V38.11 (31.1.92) und install V38.11 (20.1.92) notwendig.
Zusatzparameter bei format z.B. INTL
zu AddBuffers:
Dieser Befehl arbeitet nur mit KS2.04 V37 !!!!! und hoeher
(nach Commodore kann bei diesem Befehl auch noch unter V36
ein Fehler auftreten!!)
VT verwendet diesen Befehl nicht bei KS1.3, weil hier temporaere
Buffer nicht wieder entfernt werden koennen.
Stellen Sie bitte ein:
0 nichts dazu ;also ueberlegen Sie bitte, ob
;Ihr Speicher reicht !!!
200 rund 100 Kb
VT verwendet diesen Befehl nur bei FileTest und BlockKette. Die
temporaeren Buffer werden jeweils dem TestLW zugewiesen und am
Ende des jeweiligen Tests wieder entfernt. Bei Problemen SOLLTE
ein Fehler-Requester erscheinen. (hoffe ich ???)
Die komplette Speicherfreigabe koennen sie vor und nach VT-Be-
nutzung mit avail und addbuffers im cli ueberpruefen.
Probieren Sie Addbuffers mit der OrgWB2.04 . Es bringt Zeit.
Also erst Filetest WB2.04 ohne AddBuffers und dann mit 200 .
Empfehlung: Sollte VT anbieten, einen LinkVirus auszubauen,
so brechen Sie bitte ab und setzen AddBuffers auf 0. Sonst
haben Sie vielleicht nicht genug Speicher um das LinkFile
einzulesen, den Virusteil auszubauen und dann das Prg. wieder
abzuspeichern. Ich habe allerdings bei Tests KEINE Probleme
festgestellt.
Testbeispiel:
68030, Org-Disk-WB2.04, Org-AddBuffers df0: 5, 8Mb FM
mit VT addbuffers 0 addbuffers 200
FileTest 1:44 0:42
Hinweis fuer KS1.3-Benutzer:
Falls Sie genuegend Speicher haben, rufen Sie aus c
addbuffers df0: 200 auf . VT testet schneller . Nachteil:
Sie koennen addbuffers nur durch einen RESET unter KS1.3 wieder
freigeben !
VT - Tools :
------------
- Flush-Sp
Loescht nicht benoetigte (nicht mehr benutzte) Module aus dem
Speicher. Die MAGIC-Zahl stammt nicht von mir, sondern wurde
im FIDO-Netz diskutiert.
Beispiel: Sie betreiben DFUE. Danach ist immer noch serial.device
im Speicher (Beweis:VT/Listen/device). Nach Flush haben Sie
wieder mehr Speicher. usw.
- zeige Vec
zurueck mit Weiter-Gadget
Ausdruck mit Druck-Gadget
- zeigt wichtige Vektoren, die von Viren verbogen werden
(aber auch von einigen Nutzprogrammen)
- Konfiguration
Sollte auch unter KS1.3 und OHNE setcpu sinnvolle Wer-
te ausgeben.
Hinweis 1 :
Sollten Sie bei CPU 68030 finden und bei MMU nichts,
dann sollten Sie ihre Maschine aufschrauben und nach-
schauen, ob ihr Prozessor vielleicht die Bezeichnung
EC68030 (Billigversion ohne MMU) hat.
Hinweis 2 :
VBlank wird aus execbase+$212 ausgelesen
(vgl. ARKRM S.803 Z.129)
Neu: LoadSeg-Vektor
Sie werden staunen, wieviele Nutzprogramme inzwischen diesen
Vektor verbiegen. Rufen Sie dann Loadseg in Tools auf und
versuchen Sie einen ASCII-Text zu finden.
- SystemTest
naechste Seite: Space oder li.Maustaste
Abbruch : ESC oder re.Maustaste
Ausdruck : mit Druck-Gadget
Testet alle SprungVektoren von libs, devices und resources,
die sich im Speicher befinden. Vektoren die nicht ins ROM
weisen, werden angezeigt. Da alle Vektoren von nachgeladenen
Teilen (z.B. diskfont.library) nicht ins ROM zeigen, wird auch
ein Vektorzeiger, der nicht ins ROM zeigt und nicht mehr als
+- $6000 von einer bestimmten Adresse abweicht, als gueltig
von VT anerkannt, wenn Sie im Requester NEIN waehlen.
Beispiel: DoIo Exec -$1c8 KS2.04
-$1c8 -$1c6
$4ef9 $00f80808
JMP Sprungziel
2 4 Bytes = 6 Bytes
Sollte DoIo verbogen sein, so gibt VT aus:
-$1c6 $xxxxxxxx (zeigt also das Sprungziel)
Hinweis1: setpatch von KS1.3 verbiegt schon mehrere Vektoren !!!
Hinweis2: ab KS2.04 ist NegOff nicht immer durch 6 teilbar ohne
Rest (z.B. graphics.library und andere), sondern langwortorien-
tiert. Warum, fragen Sie Commodore !!
Hinweis3: auch ohne setpatch weisen bei KS1.3 mehrere Vektoren
von Exec.lib nicht ins ROM !!!!
- LW-Info
Ausdruck mit Druck-Gadget
Bei Disk-LW MUSS eine Disk eingelegt sein !!!
Gibt wichtige Parameter des LW`s und der Disk aus.
Hinweis: Unter KS1.2 und KS1.3 werden fuer LW DF0-3
folgende Daten NICHT ausgegeben, weil sie unbrauch-
bare Werte enthalten:
PreAlloc, MaxTransfer, Mask, BootPri u. DosType
Fragen Sie Commodore oder schauen Sie ins ROM oder DosEnvec,
da steht die unbrauchbare Tabelle fuer DF0-3. Sie finden
dann z.B. fuer Prealloc #11 usw. ?????? obwohl der Wert
richtig 0 sein muesste.
Bei KS2.04 ist der Fehler behoben.
Rechnung: UsedBlocks+FreeBlocks+2(reserved)=BlocksperDisk
LW-880Kb SectorperBlock 1 BlocksperTrack 11
HD-LW 2 22
Das HD-LW CHINON FB357A arbeitet mit ROM KS2.04 auch
im A2000C . Install schreibt entgegen meinen Erwartungen
KEINEN ANDEREN BB !!!!
Hinweis: Auch mit KS2.04 wird der BufferWert in DOS-Envec nicht
geaendert, wenn Sie AddBuffers aufrufen (Commodore-Fehler ??)
Hinweis2: Auch mit KS1.3 muss DosType (aus DosEnvec) und Disk-
Type (aus InfoData) NICHT uebereinstimmen !!! Warum ?? Bitte
fragen Sie Commodore !!
Beweis fuer KS1.3:
- mount VD0
- mountlist muss natuerlich l:fastf... und $444f5301 ent-
halten
- formatieren Sie VD0 mit FFS
- danach LW-Test
- DosType wird immer noch DOS0 sein und DiskType DOS1 !!!!
zu PC0: u. PC1: (df0: u. df1: als MSDOS-Laufwerke 720Kb)
Warum hier 1439 Blocks reserviert sind, fragen Sie am besten
die Commodore-Entwickler. Weiterhin liegen die Directory-
Eintraege meist in Zylinder 0 Block 7 und nicht wie angegeben
RootBlock=0. Suchen Sie also bitte dort nach den Filenamen.
- setze OrgVec = setzt alle wichtigen Vectoren, aber ein Prg.
wird nicht mit Nullen aufgefuellt, wie im Vorprg.
- zeige Vec = Vectorenanzeige im Hauptprogramm o h n e Virustest
- KRESET mit Sicherheitsabfrage
- KRESA3 mit Sicherheitsabfrage (fuer A3000)
(schaltet fuer sauberen RESET MMU ab)
- Base:
Ausdruck mit Druck-Gadget
Dos.lib es wird die Lage der Dos.lib im Speicher angezeigt
und nach Block 2 $00 gelegt. In Block 0 u. 1 liegen also
die negativen Offsets und in Block 2 u 3 die positiven
Offsets (Verwendung meist von Commodore nicht erlaubt).
Exec.lib vgl. Dos.lib positive Offsets von Com. erlaubt.
Graphics.lib
Int.lib
TrackDiskDevice (Struktur ist sehr kurz)
HDdev.Base sollte ein Festplattendevice finden
scram8.device ;FF 698
scram16.device ;FF 698
scsi.device Com.
hddisk.device Com.
xt.device Com.
gvpscsi.device
gvpat.device
scsidev.device GVP alt
alf.device
ALF.device
oktagon.device ;AmigaPlus 5/92 S100
BOIL.device
scsi3.device Golem
Nexus.device Advanced Systems
icddisk.device ICD
HardFrame.device Microbotics
harddisk.device Supra
SerieIII.device Supra ;AmigaPlus 5/92 S100
suprascsi.device SupraDriveXP500 ;von privat 08.09.92
vector.device HK-Computer
ivs_scsi.device Trumpcard
imscsi.device Memphis ;AmigaPlus 5/92 S100
protarscsi.device Protar ;AmigaPlus 5/92 S100
evolution.device Macro ;AmigaPlus 5/92 S100
pbscsi.device Phoenix A1000 ;Fido-Netz
MASOBOSHI.device Mastercard 2 ;Fido-Netz
Sollte ihr Festplattentreiber nicht erkannt werden, so suchen
Sie bitte in Listen - device und schreiben den Namen ab (
Bitte auf Gross- und Kleinschreibung GENAU achten). Schicken
Sie mir bitte eine Postkarte mit AbCd27.device . Danke
- ZeroPage zeigt Speicher ab $0 mit den wichtigen Vectoren
(Hallo Enforcer-Freunde)
- VecPage ab 68010 kann die ZeroPage mit movec verschoben
werden. Die Lage steht dann in VBR . VT zeigt die Lage im
Speicher und den Inhalt ab Block 0 (Unterschied zu Libs !!!)
Base - VecPage: Der gezeigte Speicherbereich kann im Filerequester
abgespeichert werden (2048 einstellen !!)
BiTMapTest
----------
Bitte verwenden Sie diesen Programmteil bei Disk-Validator-Viren
verseuchten Disketten. (FileTest und BlockKette melden Bitmap
ungueltig).
Fall1: Bitmapflag =$138 im Rootblock ist Null
VT bietet Neuberechnung an. Danach entnehmen Sie bitte diese
Disk fuer 10 Sekunden (Betriebssytem "vergisst diese Disk"). Danach
legen Sie die Disk wieder ein, Filetest muesste laufen.
Fall2: SADDAM hat Zeiger auf den Bitmapblock = $13c im Rootblock
nach $140 verschoben. VT bietet Aenderung an, danach bitte Disk
entnehmen. siehe oben
Fall3: SADDAM sitzt auch noch im Disk-Validator. VT bietet Rename
an. Neuer Name: fal.Disk-Valc (notwendig damit Hash-Wert stimmt)
Bitte Disk kurz entnehmen. siehe oben
Fall4: der schlimmste Fall, mir wurden 3 solche Disks zugeschickt.
$13c UND $140 enthalten den Wert 0. Hier braucht VT ihre Hilfe.
Loesung: suchen Sie bitte mit BitMapTest auch noch den Disk-
Validator und falls vorhanden Rename. Rename MUSS gemacht wer-
den, wenn verseuchter Disk-Validator gefunden wurde. Verseuchte
Disk bitte entnehmen und offen lassen !!!! Jetzt bitte KReset.
Booten Sie neu von einer Disk mit ORGINAL-Disk-Validator. Danach
legen Sie bitte die verseuchte Disk in DF0 oder DF1. Das Be-
triebssystem erkennt nun den $13c-Fehler und versucht den
Disk-Validator von der verseuchten Disk zu laden, was aber nicht
moeglich ist, da Sie den Namen geaendert haben (hoffentlich !!).
Also wird der saubere Disk-Validator von der Sys-Disk geladen
(Bei nur 1 Laufwerk erscheint "insert ...." 2 Wechsel notwendig!)
Das Betriebssystem schreibt nun $138 u. $13c neu (dauert eine Weile,
warten Sie bitte bis Laufwerks-LED aus ist.). Jetzt starten Sie
VT neu und decodieren IRAK-Blocks und loeschen fal.Disk-Valc .
Bis jetzt (10.07.91) habe ich so JEDE SADDAM-verseuchte Disk,
die mir zugeschickt wurde, retten koennen.
Erkennt Zombi-Disk, bitte lesen Sie Zombi-Virus-Text
Erkennt Freedom-Disk (hoffe ich), lesen Sie Freedom-Text
Kann bei Orginal-Spielen mit "echtem" FremdFormat den Root-
block ($370=880) natuerlich nicht zeigen.
Hinweis: Nach Commodore ist die BitMap gueltig, wenn im LW -1 =
$FFFFFFFF steht. Dies stimmt nur zum Teil. Da das Betriebs-
system gegen 0 testet (auch KS2.04), wird z.B. auch der Wert 1
vom Betriebssystem als gueltig angesehen.
BlockITest
----------
Abbruch: ESC oder re.Maustaste
Anzeige eines defekten Blocks moeglich (geht selbstverstaendlich
nicht bei Trackerror)
Test1:
Suche nach Trackerror's (weiss angezeigt)
- Fehler 30 SeekError Track nicht gefunden
- Fehler 29 Disk Changed Disk gewechselt
(auch wenn Sie es nicht glauben, dieser Fehler steht
manchmal in Byte 31 des DiskIoReq. Meist passiert dies,
wenn der Lesekopf zum naechsten Zylinder faehrt. Brechen
Sie den Test dann ab und starten ihn neu.)
- Fehler 28 WriteProtected wird hier nicht geprueft
- Fehler 27 BadSecHdr ungueltiger Sektor-Header
- Fehler 26 TooFewSecs zuwenig Sektoren gefunden
- Fehler 25 BadSecSum falsche Sektor-Checksumme
- Fehler 24 BadHdrSum falsche Header-Checksumme
- Fehler 23 BadSecId falsche Sektor-ID
- Fehler 22 BadSecPreamble falscher Sektor-Vorspann
- Fehler 21 NoSecHdr keinen Sektor-Header gefunden
- Fehler 20 Fehler (aber mir unbekannt)
Empfehlung: (gilt NICHT fuer Orginal-Spiele mit Fremdformat !!!!)
- mit Einzelfilecopy oder DiskSalv retten was moeglich ist
- Disk neu formatieren, falls OrginalCommodore abbricht, Disk
in den Abfalleimer. Bitte nicht mit XYZ-Format ohne Verify
arbeiten.
HinweisB Juli 92:
Falls Sie bei einer Disk Fehlermeldungen bekommen, probieren Sie
die Disk mit ihrem 2.LW. Oder machen Sie ein einfaches diskcopy
(bitte KEIN nibblecopy). Oder verwenden Sie TurboBackup. Es kann
sein, dass die kopierte Disk KEINE Fehler mehr zeigt. Allerdings
sollten Sie dann bedenken, dass ein LW sich verstellt hat. Ent-
weder ihr LW oder das LW auf dem die "OrginalDisk" erzeugt wurde.
Test2:
Suche nach Blockinhalt, der von Viren angelegt wurde:
(blau angezeigt)
- Lamer! 85 mal + 1 mal !! = 512 Bytes
- LAMER! 85 mal + 1 mal !! = 512 Bytes
- LAMER!!! 64 mal = 512 Bytes (Return of the Lamer)
- VIRUS Track 0 (Digital Emotion)
- Warsaw 85 mal + 1 mal !! = 512 Bytes
- MAD 85 mal
- 11111111 22222222 44444444 88888888 = Glasnost ab $100 im Block
- SACHSEN3 64 mal = 512 Bytes
- " Fast Eddie " = Fast Eddie ab $100 im Block
- SHIT ab $30 im Block
- 1234 ab $5a und 4E71(=NOP) 66 mal ab $64 (DiskVal1234)
Sollte ein obengenannter Block innerhalb eines Files liegen (Test
mit Blockkette), so kann dieses File NICHT gerettet werden.
- IRAK 1.Filedatenblock von SADDAM-VIRUS codiert
kann gerettet werden
(Es sind einige Nachahmungen aufgetaucht, die nicht
IRAK als Kennung verwenden. Auch diese sollte VT
erkennen und decodieren koennen.)
( Clones = z.B. LAME, LOOM, RISC usw. )
- $ABCD0008 Datenblock von Little Sven codiert.
Sollte VT erkennen und decodieren.
- Test auf $5555 (UU) wieder entfernt, da selbst mit delete und
rename erzeugt (Fastmem und FastFileSystem notwendig!!!)
Test3:
Falls Blocktyp 2,8 oder $10 erkannt wird (d.h. bei FFS-Databloecken,
BootGirlDatas oder aehnlichen Programmteilen entfaellt der 8er-Test) :
Die Pruefsumme ueber dem Block wird berechnet und mit dem 5. Langwort
verglichen.
Fehlermeldung (weiss):
- BadBloCheckSum
Hinweis zu Test3 und Festplatten mit FFS:
Bei HDs mit 165000 Bloecken waechst die Wahrscheinlichkeit, dass ein
FFS-Data-Sektor mit 2, $10 ,$20 beginnt. VT erkennt den Block nun nicht
als Data-Block, sondern glaubt einen Dir-Block oder Fileheader-Block
gefunden zu haben (je nach Kennung) und bildet eine Pruefsumme ueber
den Block. Da beim FastfileSystem keine Pruefsumme fuer Datenbloecke
eingetragen wird, meldet VT einen Fehler. Ich kann dieses Verhalten
von VT NICHT abstellen, da ich keinen einfachen Weg kenne, um einen
Datenblock im FFS entgegen der vorhandener Kennung -Dir- im Langwort 0,
als Datenblock zu erkennen. Nehmen Sie diese "Fehlermeldung" nicht
zu ernst. Schauen Sie aber ab und zu mit einem Monitor nach.
Beim alten AmigaDosSystem (auf Disk oder HD) handelt es sich SICHER
um einen defekten Block !!!!
Test4:
Alle LinkViren, die ich kenne, werden mit Blocknummer (egal ob ADos
oder FFS) weiss angezeigt. Ausbauversuch bitte mit Filetest.
Hinweis: BlockITest testet ALLE Bloecke. D.h. es kann ein LinkVirus
gefunden werden, der schon aus dem Verzeichnis geloescht ist, gar
nicht mehr aktiv werden kann und auch von FileTest nicht gefunden
wird.
Grund: Amiga-Dos entfernt bei Rename und Delete nur den Filenamen
aus dem Verzeichnis und gibt die Bloecke in der Bitmap frei. Die
FileDataBloecke dagegen werden NICHT veraendert.
Merken Sie sich die Blocknummer und setzen Sie den Blockinhalt mit
einem Diskmonitor oder Block loeschen (s.u.) auf NULL.
decode IRAK (09/10.07.91)
Block loeschen:
Zuerst bitte die Disk mit Blockkette und Filetest ueberpruefen. Ge-
meldete Fehler dort schon ausbessern. Dann und wirklich erst dann
Bloecke mit BlockITest loeschen. VT kann ein File (z.B. Jack ver-
seucht) danach NICHT mehr reparieren. Warum dann dieser Programm-
teil: weil AmigaDos die Databloecke nicht mitloescht. Ich habe
mehrere aeltere PD-Disks zugeschickt bekommen, bei denen die User
mit BlockITest nicht mehr von Dos benutzte aber verseuchte Bloecke
gefunden haben. Um diese Unruhe zu beseitigen, wurde dieser Programm-
teil eingebaut.
Ablauf:
-Block zeigen ja
-Block loeschen ja usw.
BlockKette
----------
Hinweis 13.08.92: Unter KS1.3 kann rechts oben fuer 2 Sekunden der
Hinweis " Status: validating!" auftauchen. Ein Teil der Disk ist
dann defekt. In Tools/LWinfo muesste dann auch Status: validating
stehen. Dabei kann die Bitmap IN ORDNUNG sein !!!! Dieser Fehler
wird ab KS2.04 von AmigaDos abgefangen. Die Disk ist aber irgend-
wo DEFEKT. z.B. Bad Listblock, Byte<->Block, Bad T-List usw. Die
Disk kann von AmigaDos NICHT repariert werden (von VT auch nicht).
Probieren Sie DiskSalv (Erfolg: gering). Probieren Sie BlockKette,
damit Sie die Fehlerquelle finden koennen.
SchnellStopp: Space o. linke Maustaste weiter dann wieder mit Space
Abbruch: Esc oder re.Maustaste
Testet JEDEN Block EINES Files auf Fehler (siehe bei BlockITest) und
Viren (siehe bei FileTest).
Hinweis: das alte Amiga File System arbeitet mit einer doppelten Ver-
kettung. Sollte ein "Soft"-Fehler auftauchen (z.B. bad HeaderKey), so
so kann dieser haeufig mit copy df0: to df1: all behoben werden. Bei
Trackfehlern verwenden Sie bitte z.B. Disksalv .
Hinweis: Feb 92
Es scheint ein kommerzielles Diskoptimierungsprogramm zu geben, das
die Anforderungen von Commodore (jeder DatenBlock unter OFS enthaelt
einen Rueckzeiger auf den Fileheader) in bestimmten Situationen NICHT
einhaelt und den Rueckzeiger auf den eigenen FileDatenblock zeigen
laesst.
Inzwischen scheint ein Prg. aufgetaucht zu sein, das entgegen den
Commodore-Richtlinien $00000000 als Rueckzeiger eintraegt.
Wird Halt nach jeder Seite in VT-Prefs nicht gewaehlt, so stoppt VT
bei jedem Fehler (aber nicht bei Cruncher).
Read-Bit hat keine Auswirkungen, da ueber Blockroutine gelesen wird.
Hinweis:
Die LinkViren LZ, Golden Rider und Crime! koennen hier nicht sicher
erkannt werden, da die Routine nur je einen Block einlesen kann (geht
nicht anders). Da die Viren sich ans Ende des 1.Hunks haengen kann
ein Teil der 3 Testlangworte im gelesenen Block und der andere Teil
im naechsten Block liegt. VT findet dann beim Vergleichen nicht alle
3 Langworte und meldet sich nicht. Beim FileTest SOLLEN die Viren
SICHER erkannt werden.
Hinweis: Shell hat den Wert Null. Beim EinzelFileCopy gibt es manchmal
einen Fehler. VT meldet dann der Zeiger aus dem Fileheader auf den
Datenblock stimmt nicht. Loeschen Sie das shell-File und kopieren
Sie noch einmal. Vergleichen Sie mit der OrgWB. hier meldet sich VT
NICHT !!!
BB -> Speicher
---------------
bitte DF0: oder Devs anklicken
Lade Bootbloecke in Speicher und teste
Viren, die ich habe, werden auf drei !!! Langwoerter getestet im BB
Sollte ein Virenname und vier umgedrehte Fragezeigen erscheinen,
so besitze ich den BBVirus nicht und habe ein Langwort in einer
Veroeffentlichung gefunden.
Hier lehne ich jede !!!! Verantwortung ab! Bitte schicken Sie
diese Bootbloecke an mich! DANKE!
Es wird ab VT2.33 Block0-3 gezeigt.
Festplatte: Bei der Partition mit dem niedrigsten LowCyl wird der
echte PHYSIKALISCHE Block 0 angezeigt. Bei den anderen Partitionen
der LOGISCHE Block 0. BITTE aendern Sie den ECHTEN Block 0 NICHT !!
EIN Fehler und der Zugriff auf ALLE Daten der HD wird unmoeglich !!
Speicher -> BB
---------------
bitte DF0: oder Devs anklicken
schreibe Speicher in Bootblock 0 u 1 von DfX
MERKE: Nach Track 0 werden IMMER NUR 1024 Bytes geschrieben, auch
wenn Sie vorher 2048 Bytes geladen haben !!!! Warum ? Damit mit
VT keine 4-Block-Viren installiert werden koennen !!!
Sie koennen damit also auch BBe kopieren (aber bitte keine Viren!)
Schreibbedingungen:
- 512 Bytes/Sektor
Ueberlege, bevor Du einen BB auf Festplatte schreibst !!!!!!!!!!
MERKE: Auf den physikalischen Block 0 der HD schreibt man nicht,
wenn man einen Nervenzusammenbruch vermeiden will !!!
MERKE 2:
Bitte schreiben Sie auf eine FFS-Disk NIE einen OFS-BB (und gegen-
gleich). Warum ?? Nach einem Reboot wird die Disk als OFS behandelt
und wenn Sie jetzt ein File auf diese Disk kopieren, zerstoeren Sie
die Diskstruktur. Glauben Sie nicht. Dann probieren Sie es aus. Ich
habe es auch nicht fuer moeglich gehalten, bis mir die 1.Disk so
zerstoert zugeschickt wurde.
Speicher
--------
alle Veraenderungen werden nur im Speicher vorgenommen
auf Disk wird der Speicher erst mit s.o. geschrieben
NoBoot = erstelle Blocks ohne BootPrg.
klicke:
OF fuer altes AmigaDosSystem
FF fuer FastFileSystem
insta. = erstelle bootbare Disk
klicke:
OF fuer altes AmigaDosSystem
FF fuer FastFileSystem
BLK0/1/2/3 = Wechselgadget zur Anzeige von Blk 0-3 in HEX und ASCII
Mit install (Ver.37.5 vom 28.4.91) der WB 37.67 wird ein neuer
Bootblock geschrieben, der die expansion.library patched. Ob
das bei der ROM-Version von KS2.0 auch notwendig ist, wird sich
zeigen.
Stand 27.10.91: Auch der Install-Befehl des A500+ schreibt diesen
BootBlock. Wahrscheinlich war die Entwicklung des ROM`s zu weit
fortgeschritten.
BB-KS2.0 mit expansion.library
dc.l $444F5300,$E33D0E73,$00000370,$43FA003E
dc.l $70254EAE,$FDD84A80,$670C2240,$08E90006
dc.l $00224EAE,$FE6243FA,$00184EAE,$FFA04A80
dc.l $670A2040,$20680016,$70004E75,$70FF4E75
dc.l $646F732E,$6C696272,$61727900,$65787061
dc.l $6E73696F,$6E2E6C69,$62726172,$79000000
BB-FFS-KS2.0 mit expansion.library
dc.l $444F5301,$E33D0E72,$00000370,$43FA003E
dc.l $70254EAE,$FDD84A80,$670C2240,$08E90006
dc.l $00224EAE,$FE6243FA,$00184EAE,$FFA04A80
dc.l $670A2040,$20680016,$70004E75,$70FF4E75
dc.l $646F732E,$6C696272,$61727900,$65787061
dc.l $6E73696F,$6E2E6C69,$62726172,$79000000
BB KS2.0 mit expansion.library 25.08.91
;DOS0 PruefSumme Zeiger auf RootBlock
(nicht wichtig)
000A0000 444F5300 E33D0E73 00000370
;Zeiger auf Name "expan...."
000A000C 43FA003E LEA $A004C(PC),A1
;mind. Vers 37
000A0010 7025 MOVEQ #$25,D0
;openlib
000A0012 4EAEFDD8 JSR -$228(A6)
000A0016 4A80 TST.L D0
;nicht gefunden
000A0018 670C BEQ.S $A0026
000A001A 2240 MOVEA.L D0,A1
;patch
000A001C 08E900060022 BSET #6,$22(A1)
;closelib
000A0022 4EAEFE62 JSR -$19E(A6)
;Zeiger auf Name "dos..."
000A0026 43FA0018 LEA $A0040(PC),A1
;FindResident
000A002A 4EAEFFA0 JSR -$60(A6)
000A002E 4A80 TST.L D0
;nicht gefunden
000A0030 670A BEQ.S $A003C
000A0032 2040 MOVEA.L D0,A0
;hole Zeiger auf Initial. nach a0
000A0034 20680016 MOVEA.L $16(A0),A0
000A0038 7000 MOVEQ #0,D0
000A003A 4E75 RTS
;FehlerFlag setzen
000A003C 70FF MOVEQ #-1,D0
000A003E 4E75 RTS
000A0040 dc.b "dos.library",0
000A004C dc.b "expansion.library",0,0,0
000A0060 00000000 00000000 00000000 00000000
OrgBB (frueher Lam3)
--------------------
Nur aktiviert, wenn Lamer3 oder Little Sven gefunden wurde.
Lamer3 und Little Sven verschieben OrgBB codiert nach Block 2 u. 3
Block 2 u. 3 wird entschluesselt und in Speicher geschrieben. Danach
kann man den OrgBB zurueckschreiben.
Wann nuetzt das nicht viel ???
- Wenn der Kopierschutz schon auf Track 0 beginnt (Longtrack usw)
(das Prg ist aber schon mit Lam3 nicht mehr gelaufen).
- Wenn ein File oder BootblockIntro Block 2 u 3 belegt hat.
So habe ich Lamer3 damals auf einer PD-Disk gefunden
(das File ist aber schon durch Lamer3 zerstoert worden).
FileTest: (ProgrammFileTest)
---------
- Sie haben in VTPrefs SeitenStopp eingestellt
- oder Stopp mit Space-Taste oder li. Maustaste
weiter dann wieder mit Space oder li. Maustaste
- Abbruch mit ESC-Taste oder re.Maustaste
Hinweis:
Seit KS2.0 oder FFS wird das Read-Bit getestet. Verwenden Sie
bitte bei so einem File BlockKette oder lassen Sie VT das Bit
loeschen. Die restlichen Bits bleiben im Orginalzustand.
Mit dem WB-Befehl (in c zu finden) protect oder Protect im
VT-FileRequester koennen Sie spaeter das READ-Bit wieder setzen.
- entsprechende Disk einlegen u n d warten bis LW-Led aus ist!!!
- DF0: oder Devs anklicken
Test1:
Dieser Test wird nur durchgefuehrt, wenn DOS0 (=OFS) gefunden wurde.
Teste Langwort 0 des Filedatablock auf 8 :
Fehlermeldung: bad T.DATA
Teste ob der Zeiger in Langwort 1 auf den Fileheader zeigt:
Fehlermeldung: bad HEADERKEY
Teste ob der Wert in Langwort 2 die richtige Reihenfolge enthaelt:
Fehlermeldung: bad SEQNumber
- normale Schrift: nichts gefunden
Test2:
- normale Schrift: nichts gefunden
- blaue Schrift und Requester: wahrscheinlich Virus im File
- weisse Schrift: File ist crunched oder Archiv
k e i n Test auf Virusbefall moeglich
bitte entpacken und dann neu testen
- blaue Schrift und Text: File defekt ?
Datenstruktur am Fileanfang stimmt nicht. Bitte merken Sie
sich den Filenamen und versuchen Sie das File aus dem Cli
zu starten. Hinweis: ein Fehler z.B. im 55 Datenblock eines
Files wird in diesem Programmteil NICHT erkannt !!! Verwnden
Sie dafuer bitte Blockkette.
Eine grosse Anzahl von gefundenen defekten Dateien auf einer
Disk, kann den VT zum Absturz bringen. Dies liegt NICHT am
VT, sondern am AmigaDos. Jedes defekte File im Cli gestartet,
fuehrt zum GURU. Wer's nicht glaubt, bitte selbst ausprobieren.
- findet IRQ I, IRQ II, BGS9 I-III, Disaster Master, Revenge Lamer1+2,
OrgPrg.e, die von Bgs9 I, BGS9 II oder Terrorists verschoben wurden,
XENO, JEFF-BUTONIC I+II+3.10, Terrorists, THE SMILY CANCER1+2, Traveling
Jack I+II, Return Of The Lamer (Disk-Validator), CCCP-Link
TimeBomb V0.9, TimeBomber, EM-Wurm, BRET HAWNES, SADDAM, Color,
BlueBox, LZ, Lamer-LoadWB, Gotcha, PP-Bomb, Virusblaster V2.3, Byte-
Parasite1+2+3, Freedom, initial_cli, NoGuru, Disk.info, LAMER8-File, Mem-
Check, Golden Rider, Disktroyer V1.0, CHAOS-MASTER, NoVi, Hochofen,
DATA CRIME, Crime!, Excreminator 1, IRAK+Clones, NaST, METHAMORPHOSIS,
Challenger, DARTH VADER, Crime!++, DriveInfo, DiskVal1234, LAME, LOOM,
Infiltrator, RISC, HARD,
- loescht auf Wunsch Prg.Viren
ein Requester erscheint, es ist aber auch 'Weiter' moeglich
in der startup-sequence muss bei Bedarf mit ed die 1. Zeile
geloescht werden.
BGS9 /3 VT unternimmt einen Renameversuch mit devs/A0,0
Infiltrator VT unternimmt Ausbauversuch
DARTH VADER ($A0) einfach loeschen, bitte 1.Zeile Startup-
sequence mit Editor loeschen
Challenger (setclock) VT sucht nach OrgFile in devs/keymaps,
falls nicht gefunden, wird Virus allein geloescht.
Nast=BGS9-Clone VT sucht nach OrgFile in c, falls nicht ge-
funden, wird Virus allein geloescht.
RobNorthern=BGS9-Clone VT sucht nach OrgFile in devs, falls
nicht gefunden, wird Virus allein geloescht.
Libs/Exec.library ( 4 Bytes), gehoert zu Excreminator 1
einfach loeschen
Excreminator 1
einfach loeschen
NoVi:
versucht zuerst Rename mit .fastdir,$a0
(Aenderung der startup-s. dann nicht notwendig !!)
falls File nicht gefunden wird, wird die Loeschung des Viren-
Prg.s allein angeboten (bitte dann startup-sequence aendern)
CHAOS-MASTER = dir und disk.info
wird geloescht, bitte dir-Befehl von OrgWB neu kopieren
Disktroyer V1.0:
wird geloescht, bitte startup-sequence ueberpruefen.
memcheck:
wird geleoscht, bitte 1.Zeile Startup-sequence loeschen
LAMER8-File: (haengt an VirusX)
wird geloescht, da sich jeder Orginal-VirusX besorgen kann.
Disk.info: mit Text manipuliert
wird geloescht, bitte von Orginal-WB neu kopieren
NoGuru:
wird geloescht, fuer Arbeit nicht notwendig
initial_cli: (AMIGAKNIGHT-Virus)
wird geloescht, 1.Zeile startup-sequence bitte mit ED loeschen !!
Freedom:
wird geloescht
JEFF BUTONIC V3.10:
wird geloescht, 1.Zeile startup-sequence bitte mit ED loeschen !!
ByteParasite1+2+3:
wird geloescht
Virusblaster V2.3:
wird geloescht
PP-Bomb:
wird geloescht (Bitte kopieren Sie Powerpacker 3.0b)
Gotcha LAMER:
wird geloescht (Bitte kopieren Sie bei Bedarf dir, run, cd oder
execute von Org.WB zurueck)
Lamer-LoadWB:
wird geloescht (Bitte kopieren Sie LoadWB von Org.WB zurueck)
icon.library-BlueBox-Virus:
wird geloescht (Bitte kopieren Sie icon.library von Org.WB zurueck)
color-Filevirus:
wird geloescht (Aenderung in startup-s. nicht notwendig)
IRAK-DataBlock:
decodiert den Datenblock und schreibt ihn zurueck (sehr langsam)
geht schneller mit BlockITest.
SADDAM:
loescht Disk-Validator
(Aenderung in startup-s. nicht notwendig)
BRET HAWNES:
loescht $C0A0E0A0C0 in Root
1.Zeile in startup-sequence muessen sie mit ed loeschen
EM-Wurm:
loescht $A0 in c
loescht gefundene zerstoerte Dateien auf Wunsch
Disaster Master:
loescht cls
Revenge Lamer 1 u. 2 :
loescht A0A0A0A0A0
Jeff-Butonic 1 u. 2 :
loescht unsichtb. File oder Alias-Name (s.b. Jeff-Beschreibung)
TimeBomb V0.9:
loescht .info in c
und falls vorhanden pic.xx in Root
TimeBomber:
loescht virustest
und falls vorhanden VIRUSTEST.DATA
Return of the Lamer:
loescht Disk-Validator
(Aenderung der startup-s. nicht notwendig !!)
BGS9 1+2 und Terrorists:
versucht zuerst Rename mit unsichtbarem File
(Aenderung der startup-s. dann nicht notwendig !!)
falls unsichtbares File nicht gefunden wird, wird die Loeschung
des Viren-Prg.s angeboten
Traveling Jack
loescht auf Wunsch von Jack erzeugtes File (VIRUS.xy)
- baut auf Wunsch CCCP, IRQ1+2, The Smily Cancer1+2, Traveling Jack1+2
Xeno, LZ, Golden Rider, Hochofen, DATA CRIME, Crime!, Crime!++,
Infiltrator
aus File aus
( K e i n e 100% Garantie fuer Lauffaehigkeit !!!! Falls der
Ausbau misslingt, schicken Sie mir bitte das verseuchte Orginal-
file. Danke ! )
Bei einem Fehlschlag kopieren Sie das verseuchte File auf eine
leere formartierte Disk und versuchen dann den Ausbau.
oder
Um stark fragmentierten Speicher (kann eine Fehlerursache sein)
zu beseitigen, starten Sie Kreset oder schalten Sie den Computer
eine Minute aus.
Wichtig:
Nach dem Ausbauversuch startet das Programm neu um das Zurueck-
schreiben zu ueberpruefen. Sollte das File immer noch blau sein,
so waere ich fuer eine Nachricht dankbar.
oder:
Sie haben ein File, das mehrfach von IRQ2, Smily, LZ, Golden Rider,
Crime, Crime!++ verseucht ist.
Ich besitze ein IRQ2-verseuchtes File mit sechs Links, ein Smily-File
mit vier Links und ein LZ-File mit zwei Links. Grenze bei Golden
Rider ist 100000 Bytes. Hier muessen Sie dann
ueber den File-Requester die Abnahme der Filegroesse kontrollieren und
den Ausbauversuch fortsetzen.
- sucht nach von BootControl V4.0, FileBootBlock, BB 2.0
aus BB-Viren erzeugte
Files (vgl. Fish). Entgegen meiner Erwartung laufen einige so erzeugte
Files (Laenge:1048, 1060, 1072) ohne Absturz an !!!!!
Startup-S DF0/Devs
------------------
- zeigt 2KB der startup-sequence falls vorhanden, umschalten bitte
mit BLK0/1/2/3-Gadget, hilfreich fuer schnelle Suche nach $A0 usw.
in 1. Zeile
aber bitte nicht $0A mit $A0 verwechseln !!
- zeigt n i c h t startupII oder startup-sequence.hd
(Anzeige jetzt moeglich = Umweg ueber FileRequester)
Sp -> File -> Sp = FileRequester
-----------------------------------
entfernt Aug 92 siehe Dok VT-FileReq
Devs=Device-Requester
=====================
Nimmt bis zu 30 "gemountete" Devices auf. (also kein assign, kein RAW
AUX, s usw.)
Nach 30 uebernommenen Eintraegen wird die Suche beendet.
Ende Abbruch ohne Auswahl
Auswahl mit linker Maustaste
Scroll mit PropGadget
Die "einfache" Commodore-RAM-Disk wird nicht erkannt.
was kann das Prg. nicht:
------------------------
- ist nicht speicherresident
- bitte P-Bit nicht setzen - sicherer Guru !!!!
- bitte nicht mehrere Programme gleichzeitig laufen lassen
- Virennamen aus der startup-sequence entfernen
(verwenden Sie hierfuer bitte Ihren Editor)
Es werden nur Viren ohne Reset geloescht, die ich selbst reassembliert habe.
Leider werden die Virenroutinen immer besser (immer mehr Listen und Zeiger
veraendert), sodass mit vernuenftigen Aufwand der Org.Zustand nicht mehr
hergestellt werden kann. Deshalb inzwischen auch bei einigen Viren, die
ich reassembliert habe, nur noch RESET !!
Alles andere ist mir zu gefaehrlich !! (Zeiger vergessen, Task nicht erkannt
usw.)
BEKANNTE PROBLEME:
==================
- Probleme mit Mach2.4, dann nehmen Sie bitte MachII V2.6 (z.B.Fish254)
und lesen Sie bitte Mach2.6Doc !!
Tip von J.K. fuer Mach2.4 :
waehrend des Aufbaus von VT Mauszeiger bewegen
- oder MachIII (z.B.Fish378)
- oder MachIII.1 (z.B.Fish471)
- oder Mach IV
- Probleme mit MyMenu, dann versuchen Sie bitte ParM (Fish 540)
MyMenu haelt sich nicht an die Commodorerichtlinien.
- VT meldet unter Kick1.3 eine 68030-Karte als 68020. Mit Kick2.0
wird die Karte IMMER richtig erkannt. Der Fehler liegt bei Kick1.3
(inzwischen auch in Literatur dokumentiert), da Bit 0 und 1 nicht
aber Bit 2 gesetzt werden. Abhilfe: Aufruf von setcpu (auch ohne
Parameter) setzt Bit 2.
erledigt 09.08.91: VT erkennt jetzt auch unter KS1.3 OHNE setcpu
68030/40 richtig
- Memorywert von VT und z.B. Mach III sind verschieden. Bitte haengen
Sie an MachIII-Wert 3 Nullen an und teilen dann durch 1024 (=1KB).
Sie erhalten den VT-Wert. Also rechnet VT richtig !!! Faellt erst
bei grossen MemWerten auf.
- weitere Probleme bitte melden
- Fuer Aenderungswuensche bin ich dankbar !!
Texte bitte auf Disk
(aber bitte nicht gecruncht, sondern als ASCII, Ihr
Text- oder CrunchPrg besitze ich nach Murphy bestimmt nicht)
D A N K E !! D A N K E !!
Bitte Disk mit "Viren" kennzeichnen !!!
Adresse und Tel. nicht vergessen, kleiner Text waere nicht schlecht
(Beides aber nicht unbedingt notwendig, nur das VIRUS-Prg. zaehlt)
Hinweis: Ich suche n u r Viren und neue Cruncher!! , Disk wird nach
kopieren des VirusBBs oder des VirusPrgs formatiert.
Adresse und Tel. wandert nach Virusanalyse in Papierkorb !!
(da keine Rueckfrage mehr notwendig)
Ich pflege meine Zusagen auch einzuhalten !!
Heiner Schneegold
Am Steinert 8
8701 Eibelstadt
(W-Deutschland)
Tel: 09303/8369
(19.00 - 20.00 Uhr)
bis bald !!
Heiner